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ABSTRACT 


The maintenance of large military software systems is complex, involves users as well 
as software professionals, and requires appropriate management, which is (me of the most 
important factors in efficient maintenance. Maintenance management requires information about 
the current state of the maintenance process that should be organized within a maintenance- 
oriented Engineering Database. This database should include all the necessary data about 
software changes, system configuration, maintenance task scheduling, etc., and it should be 
based on a realistic model of the maintenance process. 

This thesis proposes a mathematical Model of Software Maintenance that uses graphs to 
model the relationships between maintenance tasks and software components. The Model 
addresses the dynamic behavior of the maintenance process and supports priority and 
precedence of maintenance activities. 

The proposed Model of Software Maintenance provides a sound basis for implementation 
of a maintenance-oriented engineering database that supports automation of maintenance 
management, e.g., process control, task scheduling, job assignments, planning and forecast, 
gathering and interpretation of maintenance statistics and metrics, etc. 
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L SOFTWARE MAINTENANCE IN MILITARY SYSTEMS 


Software maintenance is the longest and costliest phase in die lifecycle of a large scale 
computer systems, especially in military use. The United States Department of Defense invested 
in software about 5 billion dollars in 1985 (estimated to reach 20 billion dollars in 1990s), 
approximately 60-70% of which were spent after it had been tested and delivered to users, 
i.e., in software maintenance [Ref. 1]. Due to the amount of resources involved, it is clear that 
any improvement in software maintenance is important and beneficial, especially for military 
organizations that are dependent on computer systems for their daily operations. 

This chapter presents the distinguishing characteristics of military software systems, main 
issues that arise in their maintenance and outlines requirements for maintenance-oriented 
engineering database aimed to improve the process of software maintenance. 

Although in general Software Engineering problems in military computer systems are the 
same as in commercial systems, the characteristics of the computer systems used by military 
organizations complicate the software maintenance tasks considerably. Understanding the 
specific characteristics of large military computing systems helps in understanding the 
complexity and addressing the problems of the software maintenance in general. 

A. SOFTWARE SYSTEMS IN MILITARY USE 

Software systems in military use can be grouped into the following major categories: 

• Embedded Software Systems. 

• Command, Control and Communication (C 3 ) Support Systems. 

• Data Management Systems. 

• Local Information Systems. 
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An embedded software system is one in which software is only a part (and usually not 
the major one) of the system. An example for such a system is a guided missile or an aircraft 
flight control subsystem. The embedded software system is ch ar acter ize d by the following: 

• The capabilities and performance of the system as a whole are determined by various 
technologies and not primarily by their software component. 

• The system is influenced directly by changes in the battlefield environment (i.e., 
introduction of new adversary weaponry, ECM Systems, etc.) and rapid adaptation to the 
new environment is essential. 

• Although the system’s usefulness and survivability as a whole is influenced by the 
operational environment changes, usually it is the software component that is the main 
factor in adaptation of die System to the new environment The main reason for this is 
due to the fact that system’s intelligence is usually concentrated in its software 
component, and therefore it is (relatively) easy to change and install the updated version 
in the operational system/equipment. 

• In order to improve performance and to make the most efficient use of existing resources 
(which are always limited due to size/weight considerations of the whole system), special 
low level hardware features and time/space optimization are utilized. 

A Command, Contrc' and Communication (C 3 ) support system is one in which a 

computer system performs a defined operational task that serves an entire organization. These 

systems have the following characteristics: 

• The system’s architecture and software are customized and are organization-dependant. 

• The system becomes a part in the daily function of the organization and performs (or 
helps to perform) operational tasks and duties of the organization. 

• Failure of the system has an immediate influence upon the organization’s operational 
capabilities. 

• The system has some real time properties and its software is (usually) the single most 
important factor in the system’s capabilities and performance. 

• Due to the characteristics of C 3 support systems mentioned above, these systems are very 
large, extremely complicated, and require very large resources and effort in development 
and maintenance. 

The data management systems category includes the traditional database systems which 
manage the organization’s information. Such systems, however sophisticated and complicated, 
do not have a direct and immediate influence upon operational capabilities of the military 
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organization, i.e., they do not have an imm ediate effect in the "battlefield situation" that the 
organization may find itself in. However, they are very important to their organizations and 
usually have a very long life span. 

The local information systems category includes systems that are targeted for local use 
and that have limited (but possibly important) influence on the organization as a whole. 
Personal computer based systems with small-scale stand-alone applications serve as a good 
example for a computer systems in that category. The local information system category can 
be characterized by the following: 

• The use of the system is restricted to specific tasks for benefit of some department of 
the organization. 

• The software in the local information system is relatively small and simple and it is 
built by using mostly "off the shelf' products and components. 

The first three categories are the most important for any military organization (that has 
them) and they are characterized by their staggering costs and longevity. Also, unlike some 
commercial applications, the military computer systems in these categories are characterized by 
the speed they must adapt to a changing environment, therefore giving a very high priority to 
maintenance tasks that incorporate the necessary changes and upgrade the system. 

Local information systems do not differ from commercial computer systems, have 
virtually no special influence upon problems of software maintenance in the military computer 
system, and are not in the scope of this work. 

B. MAINTENANCE OF MILITARY SOFTWARE 

Due to its characteristics, the military computer system and its software has a somewhat 
complicated life cycle. This life cycle can be divided into two major parts: initial development 
and the following maintenance. 

The development cycles of software and hardware components of the systems are very 
similar (at least for specification, requirement and system design phases). After all, there is not 
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much difference in the methodology of developing "from scratch" electronic components and 
of "bug proof software. In both cases, initial requirements and constraints are translated into 
functional specifications. An architecture of the system is designed to implement the functional 
specifications and then the design is built and tested against the initial requirements and 
constraints. If any of the requirements and the constraints are not met, the development team 
goes back to the "drawing board" and improves or changes its initial design. After the system 
has been completed and accepted by the user organization, die development teams are dispersed 
or diverted to other systems. Sometimes the team begins to work on an improved version of 
the delivered system. 

The maintenance phase of the system’s life cycle introduces the major differences 
between the system’s software and hardware components. 

The electronics and the mechanics of the system are maintained according to various 
organizational policies in order to insure the designed capabilities and performance. Usually, 
no engineering changes are done to the system unless a disastrous design problem has been 
discovered after system delivery, and, specifically, the system design is usually not changed 
by any maintenance activity. 

This is not the same with the software. Since software is the most flexible part of a 
system, it is usually the case that software is changed to accommodate alteration in the 
operation environment and to improve the system’s performance and reliability. This process 
is called software maintenance. Software maintenance is defined as "performance of those 
activities required to keep a software system operational and responsive after it is accepted and 
placed into production”' [Ref. 2], and it is intended to correct undiscovered faults, to improve 
performance or other attributes, or to adapt the product to a changed environment [Ref. 3]. Due 
to the fact that the maintenance phase begins after the software system is delivered to the user 

' The meaning of "placing the system into production” here corresponds to "making the system 

operational". 
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organization (i.e., when it actually becomes property of user organization), the user becomes 
responsible for the system capabilities and performance and can change it at will. 

The need for changes in military computer system arises from operational experiences 
that are accumulated while operating the system for some period of time. These changes also 
include specifications and performance discrepancies and previously undiscovered bugs. Usually, 
(especially in the case of the C 3 Support Systems) software changes are induced by the system 
itself due to the impact it has upon an organization’s operational philosophy, methods, and 
procedures. The trend of these changes is to integrate new and compatible functions to the 
system. 

Thus, besides the regular "bug fixing", software maintenance consists of engineering 
changes to the original design of the system and is actually a redesign of the system [Ref. 4]. 
These engineering changes to the original design are complex, unpredictable and cannot be 
accommodated without some iterative process [Ref. 3]. 

Although the problems in software maintenance are relevant to military and non military 
software systems alike, software maintenance of military systems is complicated by the 
following: 

• Due to high performance demands and packaging problems, military computer software 
systems are built placing more emphasis on efficiency than on future maintainability. 
This phenomenon holds true even with the latest advances in software engineering 
practices and tools. 

• Since military software systems are integrated with hardware to a very large extent and 
have direct interfaces with specific devices (especially in embedded systems), some 
modules (or even entire systems) are implemented using low level languages. 

• Due to stringent timing constraints found in most embedded and C 3 systems, any change 
of software due to required maintenance may compromise the real time performance of 
the system as a whole. 

• The field testing of weaponry systems and platforms is expensive and may result in 
physical destruction of the system. This fact strengthens the need for the best possible 
testing of the embedded software prior to new release. It also imposes problems in bug 
detection and repair, especially for fatal bugs in critical software that "surface" in 
situations that are difficult to predict and simulate. 
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• The average military software system is very large and complicated (e.g., C } Support 
Systems). In these systems every engineering change to one of die modules may have 
a "ripple" effect upon other parts of the system. 

• Sometimes, due to external factors, a number of different versions of the same system 
are in operational use by the military organization (e.g., old avionics systems with limited 
memory capacity are used along with newer systems with upgraded memory and software 
capabilities). This imposes maintenance on a number of software versions that may be 
incompatible but are interrelated in their components. 

It should be noted that the above characteristics are not unique for the military 
computing systems. Some commercial software systems may also possess such characteristics, 
although they are very few in the abundance of existing commercial computing systems and 
software. 

The maintenance problems are further complicated by the following characteristics of the 
software maintenance team (see [Ref. 5], [Ref. 6] and [Ref. 7]): 

• The maintenance team is small (compared to the development team that built the system), 
e.g., some large scale systems that were developed involving hundreds of man-years are 
maintained by teams with (usually) less then 10 programmers. Combined with the high 
volume of the maintenance tasks (especially in the large and complex software systems), 
this leads to severe limitations on the number of available maintenance programmers 
and causes a backlog in maintenance activities. 

• Few (if any at all) maintenance team members have been involved in any way in the 
original development phase of the system, thus resulting in low relative development 
experience. This may result in deficiencies in the team’s knowledge about the system, 
especially on the engineering and architectural levels. 

As a result, the task of the software maintenance team is hard and time consuming, and 
therefore costly. Programmer turnaround as well as trend of maintenance to raise the software 
complexity level of the military system while increasing its longevity contribute to the high 
cost of software maintenance [Ref. 8]. 

Sometimes this high cost is responsible for the decision to abandon the current software 
system and to develop a new one. This new software, although based upon the original 
requirements and constraints, is supposed to comply with new requirements and constraints 
that were deduced from lessons learned while using and maintaining the original system. 
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C. SOFTWARE MAINTENANCE ACTIVITIES AND PROCESS 

Software maintenance activities can be grouped into two major categories [Ref. 9]: 

• Software Update. 

• Software Repair. 

The main difference between these two categories is in the way they reflect upon the 
original functional specifications of the system: Software Repair does not change them while 
Software Update does. 

Software update activity is actually a response to the addition of new requirements or 
to the changes of an original system requirement. In military computer systems, it is as 
important as software repair and it is usually the single most important factor for the system’s 
long life span because, as a result of software update activity, the system is being adapted to 
the changing operational environment and it continues to provide required services to the 
military organization it serves. 

It involves heavy interaction with the user (or his representatives) and actually goes 
through the classic software development cycle - from requirements through functional 
specification and architectural design to implementation and testing. But, unlike ; the original 
development cycle, here the software maintenance team does not have "artistic freedom" and 
must take into consideration the existing system’s requirements, constraints, capabilities, and 
performance. This makes the software update activity the most difficult, demanding and costly 
of software maintenance tasks. Surveys of maintenance history of complex software systems 
in military use (e.g., [Ref. 6]) had shown conclusively that the majority of maintenance 
resources were spent to add new capabilities to system, while the latent defect corrections 
consumed considerably smaller maintenance resources. 

* 

; 

I 
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The software repair activities can be further classified into the following categories: 

• Corrective maintenance - fixing implementation and design bugs. 

• Adaptive maintenance • adapting the system to changes in processing or data 

environment. 

• Perfective maintenance - improving the performance and maintainability of the system. 

Since there is no software system without at least one bug, the need for corrective 

maintenance is easily understood and accepted. 

Perfective and adaptive maintenance become necessary in systems where foreseeing all 
changes (in processing and data environments) and forecasting system performance were based 
upon guesswork. This is usually the case in systems based upon new technologies with a high 
level of uncertainty. While building such systems one is concerned with the question "will it 
work?" rather than "how fast and good will it be?”. 

The maintenance process life cycle can be divided into various distinct phases [Ref. 2] 
as it is shown in Figure 1-1. 

In the first four phases of the maintenance process, the need for a system’s change is 
formulated and classified. For corrective maintenance problems this is a "touchy" phase because 
most of the problems are detected by system users as behavior inconsistencies while the system 
is in operational use. The problems that arise may be an "operator mistake" which should be 
filtered before the supposed inconsistency is brought to the attention of the maintenance team 
[Ref. 10]. In order to deal strictly with real problems, the final problem identification and 
classification should be done by someone with knowledge about system requirements and its 
expected behavior. Usually, this job requires an experienced maintenance programmer. 

For other software activities, i.e., adaptive and perfective maintenance, a formulation of 
the required system’s change is actually a statement of an additional system requirements. 

The requirements analysis phase includes problem research and cost estimation. In this 
phase the "bug” may be "hunted down" or its "natural habitat" identified. For non-corrective 
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1. DETERMINATION OF NEED FOR CHANGE. 

2. SUBMISSION OF CHANGE REQUEST. 

3. REQUIREMENTS ANALYSIS. 

4. APPROVAL/REJECTION OF THE CHANGE REQUEST. 

5. SCHEDUUNG OF THE MAINTENANCE TASK. 

6. DESIGN ANALYSIS. 

7. DESIGN REVIEW. 

8. CODE CHANGES AND DEBUGGING. 

9. REVIEW OF THE PROPOSED CODE CHANGES. 

10. TESTING. 

11. DOCUMENTATION UPDATE. 

12. STANDARDS AUDIT. 

13. USER ACCEPTANCE. 

14. POST INSTALLATION REVIEW OF CHANGES. 

15. COMPLETION OF MAINTENANCE TASK. 


Figure 1*1: Phases in software maintenance process. 





maintenance this phase should end up with a preliminary design for the affected part of the 
system. For all types of maintenance activities the requirements analysis phase should come up 
with an estimated cost of this activity and associated actions that are to be taken in order to 
incorporate die results of die maintenance activity into the system. 

The scheduling decision about a maintenance activity should be based upon the 
operational requirements of the system at that particular time. In order to reach an intelligent 
decision on this matter, close cooperation with the user is imperative and it should be done 
by a Software Configuration Control Board (SCCB) that consists of user representatives, system 
engineers and maintenance team management (see [Ref. 11]). The scheduling should take into 
account the current backlog of Maintenance activities. It should be noted that some problems 
may have utmost importance for the system and may be assigned top priority in the working 
schedule. Thus, a scheduling decision for such a problem may cause rescheduling of 
maintenance activities that had been already assigned to programmers. 

The implementation phases include the design analysis and review, code changes and 
their review, and testing of the change (preferably, in full scale mock-up of the operational 
environment). The success and cost of these phases depends very much on the quality and the 
results of the previous maintenance process phases, especially problem research. The 
implementation phases may repeat themselves until the correct solution to the required change 
has been found and implemented. 

The phases following implementation also include updating all "programming" 
documentation related to the changed component of the system together with enforcement of 
programming and documentation standards. The actual updating of the programming 
documentation should be done in each and every step that results in some change to a system's 
design and/or implementation, i.e., after each step is done the appropriate documentation should 
reflect the incorporated changes. The significance of the separate documentation step in the 
maintenance process is the auditing of the updated documentation and enforcement of standards. 
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The user acceptance and post installation review phases have great importance. Their 
main purpose is to make sure that the system’s capabilities are preserved (or enhanced), no new 
bugs are introduced and the requested change is incorporated into the system. These phases 
require close cooperation with the user and may involve updating user manuals . 

D. MANAGING AND CONTROLLING THE MAINTENANCE PROCESS 

As for the software development life cycle, management of the maintenance team must 
identify, control, and record the maintenance process by tracing all of its activities [Ref. 12]. 
Considering the software maintenance process explained above and taking into account the 
additional characteristics of maintenance in military computing systems, it is obvious that 
managing and controlling the software maintenance becomes a very complicated task. This task 
requires as much help as possible in order to make it feasible for an average human being. 

The ultimate goal of software maintenance management is to keep all systems functioning 
in a correct and required way, and to respond to all user requests in a satisfactory manner. But 
taking into account the problems and complications of software maintenance discussed above, 
the more realistic goal of maintenance management is to keep the maintenance process under 
control [Ref. 2], 

In order to achieve this goal, the maintenance manager must be able to review all 
pending change requests, plan for and schedule maintenance according to current priorities of 
the required changes. This means that the maintenance manager must process a large amount 
of information which must be formalized and accepted throughout the maintenance organization. 

The pending requests for system’s changes should be submitted formally to the 
maintenance management and should include justification of why that change should be made, 
and the priority for the implementation of this change to the system. The decision about 
requested change implementation must be formally recorded and it should include information 
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about estimated costs and implications of the change. Such a formal decision may serve as a 
trigger in change implementation, planning and scheduling. 

Taking into account the importance of maintenance activity and the efforts and resources 
required, maintenance activities may be grouped together or be performed independently. 

Performing maintenance activities on an independent basis has the advantage of bringing 
a quick solution to a problem in one part of the system, but it complicates the management’s 
task of achieving the best possible utilization of human and machine resources. Such solutions 
(usually called "patches") should be simple and quick to apply, and they should be used with 
care in order to solve some high priority problems (like fixing a bug that blocks the use of an 
important system’s feature). Usually, after introducing a number of such "quick fixes", i.e., 
"patches”, some "clean-up" maintenance activity that will incorporate these fixes into the 
"regular" code, should be performed. An independent maintenance activity (usually) does not 
introduce new system wide features, it involves a limited number of modules, and sometimes 
does not require changes to the user procedures and manuals. 

Grouping the maintenance activities together creates (in effect) a new, upgraded edition 
of the system that (usually, but not necessarily) differs from a previous version by additional 
system-wide features. This usually implies an update of the user’s operating procedures and 
manuals. Grouping of the maintenance activities allows better planning and utilization of the 
available resources for the maintenance team management and the organization as a whole and 
is a preferable practice 2 . Such grouping requires an information base of all the maintenance 
activities to be performed and a lot of planning on the part of the management. In order to 
perform such planning, the management must have at its disposal information about job 
assignments for each task, its current status (completed, at work, not started, etc.), estimated 
time to accomplish it, amount of the time spent so far, scheduling constraints, deadlines (if 


Such grouping of maintenance tasks is sometimes called "scheduled maintenance" and is in 
favor with some commercial organization's DP departments as maintenance policy. 
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any), and dependencies upon other tasks. Another type of information that is important for 

! 

| planning is data about working personnel and programmers potential and current workload. 

Due to the fact that every maintenance activity is based upon the current state of the 
system, which in turn is based upon the previous states and maintenance tasks performed, for 
maximum cost effectiveness, management considerations and judgement should be based upon 
the information concerning the history of the system maintenance with die current state having 
the strongest, but not exclusive, influence [Ref. 4]. 

One of the important tools the maintenance management has at its disposal is a software 
configuration management and control system. This system is the most si gnifi cant in 
coordinating the activities concerned with the software modules and exercising control over the 
system evolution [Ref. 13]. 

E. ENGINEERING DATABASE FOR SOFTWARE MAINTENANCE 

During the maintenance activity a large amount of information is created and processed. 
This information includes bug reports and appropriate findings, user change requests and 
resulting actions, SCCB decisions, maintenance activity costs (estimates and actual values), 
etc. Since this information has great importance for future maintenance cycles, it should be 
recorded in a system maintenance journal (see [Ref. 14] and [Ref. 9]), and it should become 
an integral part of the system’s documentation (in a broad sense). 

To use the information in the maintenance journal efficiently, it must be organized as 
a database with online access and proper retrieval facilities. In this database bug reports and 
requests for system changes can be managed and controlled, and, additionally, every 
maintenance activity can be uniquely represented by its causes and reasons, as well as its scope 
and effect. This database can and should serve as an MIS framework for the maintenance 
process and pro 1 : de a basis for tools oriented toward software maintenance management. These 
tools should provide a means for change control, software system configuration control, etc. In 
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order to do this efficiently, the engineering database should incorporate all the necessary 
information about the software configuration as well. This means that there should be a single 
and complete data repository that will save as the engineering database for all maintenance 
activities. 

The requirements for such an engineering database should include the following 
properties: 

• The database should support the software maintenance process throughout its life cycle. 

• The database must be the main repository for all the operational information concerning 
the maintenance process, i.e., for user requests for changes, requirements analysis results, 
SCCB decisions, etc. 

• The database should allow centralized control over all maintenance activities and provide 
automatic actions and operations with the possibility of manual override. 

« The database should contain all of the system’s components configuration modules (each 
in his own format, i.e., text, compilable source, etc.) and it should support a full scale 
configuration management and control system. 

• The database should reflect the inter-relationships between the software modules of the 
system and support code reusability and inheritance (as it may be required for benefits 
of Object Oriented Programming). 

• The database should provide for automatic consistency checking (based upon the module 
constraints network) and provide means and operations for automatic derivation of 
executable modules. 

• The database should provide the maintenance management with information about the 
ongoing state of the software maintenance and provide support for management decisions: 
planning, scheduling, task assignment, cost estimation, status checking, etc. 

• The maintenance process history should reside within the scope of the engineering 
database and be available (online) to authorized personnel. 

• For each type of maintenance action the database must support appropriate views of 
information and provide controlled concurrent access to relevant information for 
authorized personnel. 

• The database management system should be flexible enough to allow initial configuration 
and re-configuration for changes in software maintenance organization. 

In order to implement an engineering database that adheres to the above requirements, 

an appropriate mathematical model that ties together the software configuration information and 
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the maintenance managerial information should be established. Only after creation of such a 
model can an effective and efficient implementation of the database and appropriate tools be 
done. 

The next chapter of this work presents a Model of Software Maintenance that integrates 
the relevant configurational and managerial aspects of the maintenance process management into 
one coherent framework. This Model is intended to serve as the theoretical basis for a 
maintenance-oriented engineering database that will address the requirements described above. 



IL THE MODEL OF SOFTWARE MAINTENANCE 


The main objective of the Model of Software Maintenance is to provide a framework that 
integrates information about software maintenance activities with configuration control. The 
model is not concerned with die mechanics and the details of the maintenance prog ram mer task 
and it assumes organizational paradigms that comply with ANSI/IEEE Guide to Software 
Configuration Management [Ref. 11] as follows: 

• The management of the software maintenance organization exercises a formal type of 
change control, i.e., the system configuration changes only as a result of a maintenance 
action authorized by the management. 

• The software configuration management system is used as a tool to coordinate 
maintenance activities that occur within the context of the system, and the implementation 
of the control is done utilizing software libraries. 

• All of the verified software objects are contained in a controlled software library (i.e., 
master library) that is under direct control of the maintenance management, i.e., all 
changes to components of the master library must be authorized. 

• The actual programming work is done using the dynamic (programmer’s) library which 
is outside the master library, i.e., when each programmer is assigned to perform a 
maintenance activity appropriate software objects are copied from the maste. library to 
the dynamic one, and the programmer has free access to them: final results of his work 
are transferred from the dynamic library to the master library when his work has been 
tested, verified and accepted. 

• The products of the configuration (e.g., executable software objects) are derived from the 
system’s configuration repository and installed at the "production" site (i.e., "outside" the 
configuration repository). These software products are considered to be the "exports" of 
the configuration. 

• Since product derivation may be required at any point of time, the system’s configuration 
must be consistent at all times, i.e., at no time may derivation of executable objects be 
compromised because of consistency problems of existing completed software objects. 

Such organizational paradigms are common to most software development and 

maintenance organizations that deal with software systems of large and medium size. 
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A. BASIC CONCEPTS AND UNDERLYING MODELS 


The Model of Software Maintenance is based upon the ideas and notations of E. 
Borison’s Model of Software Manufacture [Ref. 15], the Graph Transformation Model for 
Configuration Management Environments [Ref. 16] and the observation about relations between 
the maintenance activities and the configuration of the system. 

1. Relation Between Maintenance and Configuration 

A direct effect of the software maintenance activity is a change in one or more 
components of the system. These changes affect the configuration of the system, its semantics, 
and its functionality. 

The relationship between the software configuration of the system and maintenance 
activities applied to it can be formulated as follows: each maintenance activity is a function on 
the power set of the system’s software configurations; when applied to a subset of a system’s 
configurations it results in an updated subset of the system’s configurations. In a mathematical 
sense, the system software configuration is generated by the maintenance activities; for any 
change in the system software configuration there exists some maintenance activity that leads 
to its creation. 

Therefore, we can model the evolution of the system during the maintenance phase 
of its lifecycle as a graph that consists of software objects that comprise the system 
configuration, and the maintenance tasks and activities that are applied to these objects. Such 
a graph captures the semantics of the above principles and allows creation of an abstract 
mathematical model that incorporates the specifics and necessary information of both software 
maintenance management and system configuration management and control into one coherent 
framework. 
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2. The Model of Software Manufacture 

Borison’s Model of Software Manufacture (Ref. 15] views software components as 
immutable objects, i.e., they can be created and destroyed, but once created their values cannot 
be modified. Any attempt to change such an immutable object creates a new version of this 
object that differs from the original one. Once created, the software components are not 
destroyed, they remain alive throughout the lifetime of the whole system and may be used later 
to spring off new genealogies. 

A manufacturing activity (called a step in the model) is a derivation relationship 
between two sets of components: an input set and an output set (see Figure 2-1). In the original 
Model of Software Manufacturing the manufacturing step "works" on one or more inputs and 
"produces" one or more new components. Each invocation of a manufacturing step is 
considered distinct, whether or not it operates on different inputs. Both the manufacturing steps 
and the software components are given unique labels for the lifetime of the system in order 
to distinguish between them. 

The model of Software Manufacture views the system as a finite, labeled, directed 
acyclic graph (G) of components (C nodes) and manufacturing steps (M nodes) The graph G 
is bipartite, i.e., manufacturing nodes alternate with component nodes. 

The graph G is represented by a tuple <C,M,I.O> where C and M are sets of 
nodes and I and O are sets of edges: 

• The set C represents all software components of the system. 

• The set M represents the manufacturing steps applied to the components of the system. 

• The set I represents the input relations between components and die manufacturing steps. 

• The set O represents the output relations between the manufacturing steps and the 
components. 
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INPUT MANUFACTURING OUTPUT 

COMPONENTS STEP COMPONENTS 

Figure 2-1: A Step in the Model of Software Manufacture. 

Since no component can be a product of more than one manufacturing step, the set 

O is restricted so that: 

(2-1) V M 1 JM j 6 M, If 3 CeC such that (M,.C)eO and (M,,C)eO, then M ( = 

Also, a set of primitive components (i.e., the pr. htive configuration, the one that 
is used to set up the system) can be defined as follows: 

(2-2) P ■ { CeC I ->3 MeM such that (M,C)eO) 

Let D*=(IuO)* be the reflexive transitive closure of the union of the input and 
output relations I and O, then following properties can be stated: 

• The inter-component and inter-manufacturing step dependencies are defined as follows: 
(2-3) Component C, depends on component C, <=> (C,Cj)eD‘ 

(2-4) Step Mj depends on another step M, <=>(M,.M,)€ D* 

• For any component C the set of manufacturing steps that are affected by a change in C 
is defined as follows: 

(2-5) Me ={ MeM I (C,M)eD - ] 
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A configuration in the Model of Software Manufacturing is defined as a tuple 
<GJEJL> where G is the graph described earlier, EcC is a set of components designated as 
exports of the configuration (i.e., components that are designated for a use outside of the 
configuration), and L is a labeling function that distinguishes different components of the 
system. The graph G contains only those manufacturing steps that are necessary to produce an 
export configuration of the system, i.e., the following holds true: 

(2-6) V MeM 3 CeE such that (M,C)eD' 

The original Model of Software Manufacture presented briefly above is too general, 
oriented towards use of tools and application of derivation transformations to some components 
in order to create others, and is concerned only with manufacturing steps that result in export 
components. Also, the components in the Model of Software Manufacture are not limited to 
conventional software modules (e.g., source code files) and actual parameters for tool 
invocations are considered to be "legal" components of the model. The manufacturing steps 
have no concrete existence, they are taken to be the derivation relations between inputs and 
outputs. 

The Model of Software Manufacture is not suited for the specifics of maintenance 
tasks, and it must be refined in order to serve as a model for software maintenance process. 

3. Relations Between Software Components 

The Graph Transform Model [Ref. 16], classifies software objects into two 
categories: re-derivable and non-re-derivable. Re-derivable objects can be automatically 
reconstructed by applying some tool to some set of software objects. All other objects are 
considered non-re-derivable (e.g., "source" objects). The software objects may have attributes, 
which can specify computational procedures that should be applied to the components in order 
to perform specific transformations. 









There exist two important relations between non-re-derivable and re-derivable 
objects: is-component-of and derives. These relations have a direction and are easily modelled 
using digraphs (see Figure 2-2). 




’ DERIVES 
RELATIONSHIP 


•• IS-CONPONENT-OF’ 
RELATIONSHIP 


Figure 2-2: Example of Relations Between Software Objects. 

The relation "derives" is defined between non-re-derivable and re-derivable objects 
and it represents a transformation of one or more software objects into another (e.g., 
compilation of source modules into linkable object modules). The "derives" transformations are 
typed transformations that are applied to objects of a specific type. These transformations are 
very specific, they are known a-priori, and can be applied automatically using the information 
about the type of the software object and the attributes of the object itself. The "derive" 
transformations are associated with the use of software tools in the process of programming, 
and they usually are invisible to the management or users of the system. 

The "is-component-of" relation is defined between non-re-derivable objects only and 
it represents the use of one component by another component of the system (e.g., use of 
packages in the ADA programming language). To denote the "is-component-of" relation we will 
use a convention in which the "is-component-of’ relation between components C, and C, means 
that C ( is a component of C r 
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The "is-componeni-of' relations between components are defined by the software 
system overall design and module decomposition. These relations may be specified in the 
compone n t itself (e.g., using compiler directives in progr am ming languages - "#inchide" in C, 
"with" in ADA, "COPY" in some COBOL dialects) or explicitly stated as attributes representing 
additional information required for deriving transformations (e.g., library specifications in linking 
commands). In both cases the relation information is defined a-priori, and is stable relative to 
the dynamics of the software changes due to the maintenance process. These stable relationships 
may change as a result of maintenance, but these changes are few and far in between compared 
to die changes in the components themselves. 

B. CONFIGURATION GRAPH OF THE MAINTENANCE MODEL 

The Model of Software Maintenance is comprised of two basic elements: system 
components and maintenance steps. 

The system components are immutable and non-re-derivable software objects. The system 
components of the Model of Software Maintenance correspond to the components in the Model 
of Software Manufacture, with the exception that the components must have concrete existence 
as software objects of the system. Programming tools and their invocation parameters are not 
considered to be system components in the model. Systran components are henceforth called 
components. 

The maintenance steps correspond to manufacturing steps of the Model of Software 
Manufacture with the following differences: 

• A maintenance step is a "representation" of the organizational activity concerned with 
initiation, analysis and implementation of one request for a change in the system. 

• A maintenance step may be atomic (i.e., applied to at most one system component and 
produces at most one output component), or be composed from a number of atomic 
steps. 

• A Model of Software Maintenance allows for the existence of empty steps that do not 
produce output components. 
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• The model also allows for existence of "dead moves" (i.e., steps that do not lead to 
production of "useful” components). The existence of such steps is motivated by the need 
to keep correct records of all maintenance activities, including those that have taken a 
"wrong turn". 

• Deriving transformations are not considered to be maintenance steps and are not 
represented in the Model. 

Additionally in the Model of Software Maintenance, for each maintenance step a scope 
of a change is defined as all sub-systems (or systems 3 ) to which the step is applied. 

The system configuration is an acyclic directed graph (digraph) G of components (C 
nodes) and maintenance steps (M nodes), in which the components and steps are connected by 
two relations: inputs (I arcs) and outputs of the maintenance steps (O arcs). The output 
relations of maintenance steps are defined between a maintenance step and the non-re-derivable 
component it produces. Tbe input relations are defmed between a maintenance step and the 
system components which are necessary to produce an output component that is consistent with 
the rest of the system. Naturally, no component that has an output relation with a maintenance 
step can have an input relation with the same step, i.e., no input and output "feedback" 
relations are allowed. This extends to any path of relations, thus avoiding cycles and complying 
with tbe requirement that G is acyclic. It should be noted that input and output relationships 
between components and atomic maintenance steps define a bipartite digraph. 

We will represent the input and output relations by sets of the components for which the 
relations hold. We will use notation in which for a maintenance step M, (where q stands for 
the step’s label, e.g., an index in an enumeration) its input and output sets are denoted 1^, and 
O,*, (respectively). Ih, and 0*, are sets of system components which have input and output 
relations with the step M,, respectively (see Figure 2-3). 


3 


The exact definition of a system will be provided later. 
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Figure 2-3: An example of a Maintenance step. 

We can formalize some of the basic principles and definitions of the Model of Software 
Maintenance as follows: 

(2-7) V maintenance steps M, IImI > 0 and I0 M I < 1. 

(2-8) M is an empty step iff O m = I* = 0. 

(2-9) For all maintenance steps M, if I„ * 0 then IO M l * 1. 

(2-10) If component CeO„, then Cel^. 

(2-11) V M,,M j eM, If 3 CeC such that (M^QeO and (M,,C)eO, then M i = M r 

(2-12) P * 1 CeC I -0 MeM such that (M,C)eO} 

(2-13) Let D’=(IvjO)’ be the transitive closure of the union of the input and output 
relations I and O, then 

a) Component C, depends on component C, <=> (C„Cj)€D'; 

b) Step Mj depends on another step M, <=>(M i M j )e D’; 

c) Set of steps affected by a change in component C M<- = {MeMI(C,M)eD') 
It should be noted that the properties (2-11) - (2-13) of the Model of Software 

Maintenance are similar to properties (2-1) - (2-5) of the original Borison's Model of Software 
Manufacture, upon which the Model of Software Maintenance is based. 
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C. MAINTENANCE STEP STATES 

During the execution of the maintenance process the maintenance activity, which 
corresponds to a step in our model, can be in several possible states (see description of the 
maintenance process in previous chapter). These states represent some of the dynamic aspects 
of the maintenance process initiated as a result of a system change request. 

For the purposes of the Model of Software Maintenance the following five states of a 
maintenance step are defined: 

• Invoked. 

• Pending. 

• Implementing. 

• Completed. 

• Abandoned. 

Each of the above states corresponds to several phases of the maintenance process 
described in [Ref. 2], and corresponding sub-states can be defined for each of the above states 
in the implementation of the model. For brevity we call a maintenance step by the name of 
the state it is in, e.g., "pending step", "implementing step", etc. 

Transition of a maintenance step from one state to another (see Figure 2-4) is performed 
as a result of an explicit decision made by maintenance organization management. By 
controlling the states of the maintenance steps, the maintenance management exercises direct 
control over both the software maintenance process and the system configuration. 

In the "invoked” state the maintenance step is created according to a requirement for a 
change in the system. In this state the originated change undergoes analysis which estimates 
the resources required for the step’s implementation, designates inputs and defines the scope 
of the step. At this stage the maintenance activity is not yet approved for implementation, and 
it is not yet linked to any component of the system. If the maintenance activity is not approved 
by SCCB, then the maintenance step state becomes "abandoned". 
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Figure 2-4: Maintenance Step States and State Transitions. 


In the "pending" state the maintenance step is approved but it has not yet started its 
implementation phase. In order to be implemented, the pending maintenance step must be 
scheduled and assigned to a programmer. Scheduling of a maintenance step should resolve all 
possible inconsistencies that may arise as a result of concurrent implementation of the pending 
steps. A maintenance step in the "pending" state can be "abandoned" (i.e., transferred to 
"abandoned" state) and forgotten there. 

In the "implementing" state the actual implementation and testing of the requested change 
is performed. At the transition to this state from the "pending” state, the binding of input 
components occurs, and the output component is created. At this stage, the output component 
is a placeholder for the future component contents of the maintenance step results, i.e., the 
output component is "empty” at the beginning, and its contents are produced during the 
implementing phase of the maintenance step. It should be noted that this behavior does not 
compromise the immutability of the components, since the immutability feature is applied after 
the component is created, i.e., after the "implementing” state has been completed. Also, note 
that the "implementing" state can be "rolled back" into the "pending" or "abandoned" state, and 
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in such a case the output of the step is invalidated and is no longer a component of the 
system. 

The "implementing" state changes into the "completed" state after the requested change 
implementation is done and tested. At the transition to this state the output component’s 
contents are frozen and entered into the system component repository and it becomes an 
approved member of the system. Then the step itself terminates and becomes part of the 
permanent record of the system. 

The "abandoned" state is the final state for all maintenance steps that were not approved 
by the SCCB or "killed" by the management in the "pending" and "implementing" states. 

It should be noted (see Figure 2-4) that only the maintenance steps in the "implementing" 
state can be "rolled back" into "pending" state. By doing so all the work that had been 
performed to implement this maintenance task may be lost due to later changes in the system 
that may affect the "rolled back" step. Therefore such decisions should be made with insight 
and great care. 

D. MAINTENANCE STEP INPUTS 

The nature of an atomic maintenance step is to incorporate a single change in a single 
component of the system. We will call such a component a primary input of the atomic 
maintenance step (see 3), and we will limit the number of primary inputs for an atomic 
maintenance step so, that: 

(2-14) V maintenance step M 3 at most one primary input Cel*,. 

In order to capture the semantics of dependencies of some system components on other 
components (as defined in (2-13)), we will introduce the notion of non-primary inputs of a 


27 











main tenance step. The non-primary inputs of die maintenance step M belong to I*,, the input 
set of this step, and they are defined by its result: 

(2-15) For a maintenance step M, the set I*, consists of the primary input and all other 
components that are used in creation of the component Ce 0*, and in the deriving 
transformations that produce other software objects from it. 

It immediately follows from (2-15) that: 

(2-16) If 3 an "is-component-of' relation between C, and C,e O*, then Cje I**,. 

The non-primary inputs may be determined manually or automatically using knowledge 
based techniques. If the primary input C, of a maintenance step M, is a primitive component 
(i.e., C,€ P as defined in (2-12)), then the non-primary inputs of M, can be computed from the 
"is-component-of* relations of system components with the component C, (see Figure 2-3). 
Otherwise die inputs of die pre vi o u s step M,, with C ( eO^ may be used to compute the set I*,. 
Facilities for updating the input set of a maintenance step in the pending and implementing 
states must be provided in the implementation of the Model. 

It should be noted that the existence of the inputs for the maintenance step is not a 
necessary condition (see (2-7)). There may exist a maintenance step without inputs that 
produces an output component Also, there may exist a maintenance step with non-primary 
inputs only that produces an output component An example for a such case is the creation of 
a new component by merging the contents of a number of existing components, although it 
should be noted that there exists another way to represent such merging: one component can 
be the primary input of the maintenance step that performs the merging, while other 
components that are used in the merging process, become the non-primary inputs of the 
merging step. 


28 










E. DESCENDENCE RELATION, GENEALOGY TREES AND SYSTEMS 

We will define a descendence relation by saying that primary input C, of a maintenance 
step M is an ancestor of the resulting component Cj6 O m , and that the component C,e O m is a 
descendent of C,. 

Descendence is a transitive relation, i.e.,: 

(2-17) Component C^eO*,, is a descendent of C, iff C, is the primary input of a step 
or the primary input of Mp is a descendent of C,. 

In order to distinguish between types of descendence relations for later use, we will call 
the non-rec<irsive descendence a direct descendence. 

The descendence relation defmes evolution genealogy (called genealogy for shorthand) 
subgraphs of the configuration graph G. These subgraphs are created using only the primary 
input and output relations of the maintenance steps. Because the graph G is acyclic, and due 
to the restriction of at most one primary input for a maintenance step, each element of the 
genealogy subgraph is a tree. Thus, die following hold true: 

(2-18) All descendants of a component C belong to the genealogy tree T that has C as 
its root or one of its nodes. 

(2-19) There exists a unique path between component C and any of its descendants. 

We call a genealogy tree with a component C as its root a C genealogy tree and we will 
denote it as T c . A genealogy tree can be a subtree of other genealogy tree(s), or be a spanning 
tree, which is defined as follows: 

(2-20) T, is a spanning tree <=> -i3 T Jt i*j such that T ( c T,. 

Using the notion of genealogy trees we can define software systems (or products), and 
we will say that a software system S is uniquely identified by a set of genealogy trees that 
comprise it, i.e., S *= {T,}. It should be noted that the whole system is defined by a set of all 
spanning genealogy trees, and in the case of a sub-system, the genealogy trees T, are not 
necessary spanning. Since sub-systems themselves can be viewed as systems, we will not 
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distinguish between them unless it is required. The following rules apply to both systems and 
sub-systems alike, since software products can be viewed as either systems or sub-systems. 

We will say that software system S is complete if the following holds true: 

(2-21) V T,e S, if 3 Tj I Qe T, depends on C„€ T, or C, is a component of Q, then the 
tree T,e S. 

We can express the relations between components and systems as follows: 

(2-22) Component C, € S <*> 3 T k I C, e T k and T k e S. 

We also can define the scope of a change for a maintenance step (denoted as Km,) that, 

as mentioned earlier in this chapter, represents software (sub)systems to which the maintenance 
step is applied: 

(2-23) if is a scope of step M, with primary input C, then KM,£US,IC,e S,. 

The inclusion K*, s uS } in the above rule means that there may be a situation in which 

(by a virtue of a maintenance management decision) an influence of a maintenance step will 
be limited to particular (sub)systems. 

F. DESIGNATING PRIMARY INPUT FOR A MAINTENANCE STEP 

Designating a component C as an input to a maintenance step means that this step will 
take the component C or one of its descendants as a primary input. Such a designation is 
possible only for pending maintenance steps, and it does not prevent the use of this component 
by other maintenance steps, i.e., it does not "lock" the input component. 

The actual binding of primary input with the designated component can be performed 
only if the input component is available and it is done at the transition time of the maintenance 
step from the "pending" state to the "implementing" state, after the step is scheduled and 
assigned to a programmer. After the primary input is bound to the implementing maintenance 
step, its non-primary inputs are determined. 







The primary input component is available for a maintenance step if it is a primitive 
component or it was created by some completed maintenance step, i.e M it exists and is not 
currently being worked on: 

(2*24) A component C is available iff Ce P or 3 completed M such that Ce O m . 

Components that are currently under work by some uncompleted maintenance step may 
be used as non-primary inputs of a step, and they are considered available the moment they 
are created by an implementing maintenance step. 

The designation of a primary input component to a maintenance step can be specific or 
generic. When specific designation is done, the maintenance step will be applied to some 
specific component that already exists in the system, e.g., to a specific version of the primitive 
component. There is no possibility of specifically assigning a component that is not produced 
yet. 

In the case of a generic designation of component C, the maintenance step will be 
applied to the available descendent of C. As mentioned earlier, the actual binding of the 
primary input to a component that belongs to the genealogy tree of C will take place when the 
maintenance step begins its implementation phase. For example, in the case of a generic 
designation, if there are several maintenance steps with the same designated input component 
C, then the first maintenance step is applied to the component C, the second is applied to the 
descendent of C, and so on. 

It should be noted that, because of the possibility of creating "parallel" genealogies that 
originate from the component C, the generic designation may not be unique. 

G. DECOMPOSITION OF MAINTENANCE TASKS 

Sometimes, after analysis of a requested change that initiates a maintenance step, it 
becomes apparent that the implementation of the original change leads to changes in several 
system components. The original request for a change is represented as a maintenance step. 
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However, because a maintenance step can be applied to at most one primary input and 
produces at most one output component, the maintenance step invoked by the original request 
for change becomes a composite maintenance step; it "spawns" a number of new atomic 
maintenance steps. In such cases, it is important to record a relation between the composite step 
and die steps that are "spawned" by it. We will call this process "step decomposition ", the 
relation "spawned", the composite step a "spawning step " and the newly invoked steps 
"spawned'. The step decomposition process is recursive, i.e., spawned steps may themselves 
be composite maintenance steps. 

In order to eliminate the possibility of unnecessary relations between composite steps and 
their spawned steps, the composite maintenance step may not produce any new component by 
itself, i.e., it is an empty step. 

The composite step decomposition takes Diace when the step’s implementation is 
authorized and it creates a set of spawned steps. These spawned maintenance steps are created 
directly in the "pending" state, i.e., they are considered to be authorized by the virtue of 
authorizing the composite step. The spawned steps behave normally, meaning that they do not 
differ from non-spawned maintenance steps and they may have relations with one another or 
some other maintenance steps. Because the spawning step is an empty step, there are no 
dependency relations between the spawned steps and their spawning steps. 

In order to provide consistency in treating composite and atomic steps, the following 
constraints are imposed on some state transitions of the spawning and the spawned steps: 

(2-25) The spawning step is transformed automatically from pending to implementing 
states when one of its spawned steps performs this transition. 

(2-26) The spawning step performs an automatic transition from implementing to 
completed state when all of its non-abandoned spawned steps have done so. 

(2-27) Abandoning a spawning step will automatically abandon all of its spawned steps. 

(2-28) The transition of a spawning step to abandoned state is done automatically when 

all of its spawned steps are abandoned. 
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It should be noted that, since all spawned steps are intended to implement a specific 
maintenance task, a single maintenance step (atomic or composed alike) can be spawned 
directly by only one composite maintenance step, i.e., the graph formed by a spawning 
relationship is a tree. 

H. INDUCED MAINTENANCE STEPS 

An engineering change in a key component of a software system may compromise the 
consistency of systems that belong to the scope of the step by affecting other components of 
these systems in such way that some action is required in order to keep them consistent. For 
example: a change in the specification of some ADA package requires some action to be 
performed on all other components that use this specific package before any new software 
product can be successfully derived. 

We will define an induced maintenance step as a step that must be performed in order 
to keep the system’s consistency due to a result of another maintenance step. The importance 
of induced maintenance steps >s in alerting the maint-liners and the management to changes in 
key modules of the software product and enforcing constraints on performing any uncoordinated 
maintenance step on the affected components. 

It should be noted that a change in one component may trigger a change in another, 
which may in turn trigger a change in third component, and so on, i.e., the changes may be 
triggered recursively. We will call a component that originated the change propagation a 
triggering component, and the step that uses it as its primary input an inducing step. 

Additionally, the propagation of the changes triggered by an inducing step must be 
restricted to the scope of the inducing step. 

In order to define specifically the relevant maintenance steps that are affected by a 
change in component C, we will introduce the concepts of latest descendent and latest 
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maintenance step. The latest descendent of a primitive component is a component that is not 
used as primary input by any maintenance step, i.e.,: 

(2-29) C, is a latest descendent of Cj iff C, is a descendent of Cj and ->3 M, such that 
C, is die primary input of M,. 

The latest maintenance step is defined as follows: 

(2-30) Step M is the latest step with respect to C, iff the component C,eO M is latest 
descendent of C r 

We refine the original definition of the set Me (see (2-13)) using the notion of the latest 
maintenance step as follows: 

(2-31) Me,, the set of maintenance steps affected by a change in triggering component 
Cj, consists of latest steps M which have Cj as their non-primary input and O m 
belongs to the scope of an inducing step that implements the change in C r 

Since a change in one system component may lead to the inconsistencies with the 
primitive components (i.e., the components that were not produced by any maintenance step), 
the above definition is not sufficient and we will introduce the notion of an affected 
component. A system component, whose consistency with the rest of the system is affected by 
a change in some other component, is called an affected component and the following holds: 

(2-32) A component C, is affected by a change in Cj iff C, belongs to a scope of an 
inducing step that implements the change in Cj and either C,eO M where step 
MeM CJ or both C,eP and Cj€P and C t is a component of C,. 

Analogous to the definition of the set M CJ (see (2-31) above), we can define a set of all 
components that are affected by a change in a component Cj (noted as C cj ), using the recursive 
nature of the propagation of a change, as follows: 

(2-33) A component C belongs to the set C cj if C is affected by a change in Cj or C 
is affected by a change in C,eC C j. 

If CjcIm,, is a primary input and the set C cj is not empty, then the inducing step M,, 
induces maintenance steps M* 0) \ where n=l,2,..,IC Cj l. An induced maintenance step takes 


The notation M* 0) is used as a labeling for induced maintenance steps. 


34 







an affected component Ce C cj as its primary input, and produces as its output a new component 
which is consistent with the direct descendent of die component Cj. 

Uncoordinated propagation of the induced steps may cause the transient state of the 
systems configuration to be inconsistent. For example, a change of the package specifications 
without coordinated change of the package body may cause some incompatibilities and 
compromises the consistency of the whole system. 

In order to keep the system configuration consistent, the inducing main tenance step 
together with its induced steps are performed as an atomic step, i.e., an inducing step and all 
of its induced steps (including those that were created recursively) should appear to perform 
their transitions from "pending" to "implementing" states and from "implementing” to 
"completed" states simultaneously. The following rules impose a semi-atomic behavior of 
inducing/induced steps by introducing the necessary constraints: 

(2-34) An inducing step M, with primary input can start its implementation phase iff 
all steps M^gMcj are completed. 

(2-35) An induced step M*,, with primary input C,e C cj can start its implementation 
phase iff the inducing step M, with primary input C } has already done so. 

(2-36) An inducing step M, with primary input can become completed iff all induced 
steps with primary input C,eC c , are completed. 

(2-37) Any "roll back" transition of the inducing step causes the same transition to be 
performed on all its induced steps. 

(2-38) An induced step can be "rolled back" only by "rolling back" all of its inducing 
steps. 

(2-39) Abandoning an inducing maintenance step causes all of its induced steps to be 
abandoned. 

(2-40) An induced step can be abandoned only by abandoning its inducing step. 

The meaning of rule (2-34) is that the inducing step cannot begin its implementation 
before it assures that all steps that it affects (see (2-31)) are already completed, and the primary 
inputs for its induced steps are available (see (2-24)). Rules (2-35) and (2-36) mean that the 
induced maintenance steps cannot begin their implementation before their inducing maintenance 
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step, and the inducing step cannot complete (he implementation phase before its induced steps. 
Other rules mean that the induced step has no reason to exist by itself, without its inducing 
step. 

Because of the dynamic nature of the system’s configuration, the influence of an inducing 
maintenance step with primary input Cj (i.e., the contents of the set C cj ) may vary. The 
contents of the set C cj become static as a result of scheduling of the step M,. Since the induced 
steps M* 0) depend directly upon the contents of they are invoked immediately after the 
inducing step M, is scheduled f or execution. 

L EXAMPLE OF MAINTENANCE STEP DYNAMICS 

A simplified example of maintenance step dynamics is presented in Figure 2-5. The 
example represents maintenance activities applied to a system that consists of five components: 
setsspec, setsbody, graphsspec, graphsbody, and frontend. The system in the example 
represents graphs using sets, performs operations on them and presents the results to the user 
through procedures in the front end module. 

The example shows influence of a simple maintenance step on the system configuration, 
creation of distinct evolution genealogies, and creation and propagation of the induced 
maintenance steps. 

The set of primitive components of the system consists of the following five modules: 
P * (sets_spec.Vl, sets_body.Vl, graphs spec.Vl, graph sbody. VI, front end.Vl} 

The "is-component-of" dependencies of the primitive components are defined and shown 
on the left side of the primitive components in the figure. 

In the example, a request for a change in one of die front end procedures initiates a 
maintenance step M, with the designated primary input front_end.Vl. After the step is 
scheduled and implemented, it creates the new component front_end.V2. which is a direct 
descendent of the front_end.Vl component. 
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Figure 2*5: Example of Maintenance Steps Dynamics. 


The non-primary inputs of the step M, are determined using "is-component-of' relation 
and they consist of components graphsjspec.Vl and sets spec.Vl. 

A request for a change in the component graphs_body.Vl initiates maintenance step M 2 , 
which results in the production of a new component graphs body V2. Another request for a 
change that corresponds to the maintenance step Mj has a component graphs_body.Vl as its 
specific designated input and it results in a component graphs_body.V2a, giving rise to an 
evolution genealogy which is "parallel" to the one created by the maintenance step M 2 . 

The component sets_spec.Vl is used as a non-primary input in a number of maintenance 
steps, and a change in it will affect the following set of components: 

C*. ^ VI «{sets_body.Vl, graphs_spec.Vl, graphs_body.V2, graphs_body.V2a, front_end.V2} 
This set is computed recursively, starting with the set of components that are directly 
affected by sets_spec.Vl (i.e., the set |sets_body.Vl, graphs_spec.Vl, front_end.V2|), and 
then for each component in the set adding the components which it affects. 
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A maintenance step M 4 that implements a change in the sets_spec.Vl component induces 
the following maintenance steps: 

• Step that produces component sets_body.V2. 

• Step M«j, that produces component graphsjspec.V2. 

• Step M«„ that produces component graphs_body.V3a. 

• Step M^, that produces component graphs_body.V3. 

• Step M*(j) that produces component front_end.V3. 

The step M* is completed only after all the maintenance steps it had induced (i.e.. 
are completed. Thus, the implementation of the inducing and induced maintenance 
steps is performed atomically, keeping the whole system consistent, i.e., any software object 
derived from the system co m po n ents will be consistent with the latest changes incorporated in 
the system. 

J. PRIORITY AND PRECEDENCE OF MAINTENANCE STEPS 

During the life cycle of the software system, constraints that reflect the urgency and the 
partial ordering of the maintenance tasks arise from real life situations. These constraints 
influence the process of software maintenance, and they must be represented in the Model of 
Software Maintenance in order for the latter to be a realistic model. 

We will represent the urgency of the maintenance tasks by assigning a small positive 
integer value as a priority value to each maintenance step that is needed to implement the task. 
The priority values of the maintenance step represent the relative urgency of the maintenance 
tasks, and they suggest an implementation ordering of the maintenance steps. 

The priorities are assigned manually to the maintenance steps by an appropriate forum 
that includes the user (or his representatives) and the maintenance team management (e.g., 
SCCB), and they may be changed during the maintenance process according to the state of the 
system maintenance and external constraints. The process of assigning priority values to 
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maintenance tasks may use different methods and algorithms and is external to the Model of 
Software Maintenance itself. 

Since the priorities are assigned to the maintenance steps according to the maintenance 
task, the following property should be preserved: 

(2-41) If maintenance steps M, and M, are intended to implement parts of the same 
maintenance task, then steps M, and M, are assigned the same priority value. 

In the case of assigning priorities to composite or inducing maintenance steps, the 
following defines die priorities of the spawned and the induced steps: 

(2-42) If composed/inducing step M, is assigned a priority value N, then all maintenance 
steps M,, that are spawned/induced by the step M, are assigned the same priority 
value N. 

The priority mechanism should not be misused, e.g., all maintenance steps should not be 
assigned the same priority. It is advisable to keep the range of the priority values as small as 
possible without altering their meaning. 

In addition to the partial ordering that arises from assigning the priority values to 
maintenance steps, there may exist additional constraints that impose ordering constraints 
between two or more steps. These constraints may represent specifics of a maintenance task 
or inter-step dependencies that cannot be expressed by die input and output relations of the 
maintenance steps as defined in (2-4) and (2-13). The intent of such ordering constraints is to 
impose a sequential rather than a concurrent execution of the maintenance steps. 

To account for the execution ordering ranking, we will introduce the " precedes " relation 
which is defined between pending atomic maintenance steps as follows: 

(2-43) If atomic step M, precedes atomic step M,,, then the step M, must be completed 
before the step M, begins implementation. 

t 

Because of the semi-atomic nature of induced maintenance steps (see (2-34) - (2-40)), 
the following holds true: 

(2-44) If inducing step precedes (or is preceded by) step then all induced steps 
M^„, precede (or are preceded by) the step 
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(2-45) If induced step M^„ precedes (or is preceded by) step M,, then its inducing step 
M, precedes (or is preceded by) the step M,. 

(2-46) An inducing step M, cannot precede its induced steps and vice versa. 

Naturally, similar constraints apply to composite steps and the steps that are spawned by 
them, i.e.,: 

(2-47) If atomic step M, precedes composite step M,, that the step M, precedes all the 
maintenance steps spawned (directly or recursively) by the step M,. 

(2-48) If composite step M, precedes step M,, then all steps spawned (directly or 
recursively) by the step M, precede the step M,. 

The "precedes" relation is transitive, asymmetric and irreflexive, i.e.,: 

(2-49) If step precedes M, and step M, precedes M,,, then step M, precedes step M,,. 

(2-50) If step M, precedes M,, then step M,, cannot precede M,. 

(2-51) V steps M„€M, M,, cannot precede itself. 

The transitive and the asymmetric properties of the "precedes" relation imply that the 
graph of the "precedes" relation is acyclic, i.e., the situation in which step M, precedes M,> step 
M, precedes M,,, and step M,, precedes step M, is impossible. Also, the situation in which a 
spawned maintenance step precedes its spawning step is illegal. 

Unlike the priority values that suggest an implementation ordering, the "precedes" relation 
imposes a strict ordering between two or more maintenance steps, e.g., in (2-43) the step M, 
will be implemented before the step M,, even if the priority of the step M,, is higher than that 
of the step M,. Therefore the ordering imposed by die precedes relation is "stronger" then the 
one we would obtain using only the priority values of the maintenance steps. 

The "precedes" relation must be consistent with the dependency relation between 
maintenance steps (as defined in (2-13)), since the dependencies that propagate through the 
primary inputs impose the "precedes" relation between the steps: 

(2-52) If 3 C ( g C such that C,€ and C ( is the primary input of step M,,. then the step 
M, precedes step M,,. 
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Also, there exist implicit precedence relations that concern inducing maintenance steps 
(see (2-34)) which can be stated explicitly as follows: 

(2-53) If 3 inducing step M, with primary input C Jt then V steps M, e step M, 
precedes maintenance step M,. 

Recall that the "precedes" relation is not concerned solely with step dependencies that 
propagate through inputs of a maintenance steps. It deals also with the constraints that are 
external to the system configuration. 

The "precedes" relations between maintenance steps should be defined by the maintenance 
management, and it is their responsibility not to misuse this mechanism. An incorrect use of 
the "precedes" relation will lead to introduction of many unnecessary constraints in the 
scheduling of the maintenance steps. On the other hand, the correct use of the "precedes” 
relation should improve the effectiveness of the maintenance process. 



IEL UTILIZATION OF THE MODEL OF SOFTWARE MAINTENANCE 


Chapter II presents a Model of Software Maintenance that integrates the configurational, 
behavioral and managerial aspects of software maintenance and provides a conceptual 
framework for implementation of a maintenance-oriented engineering database introduced in 
Chapter I. 

The main purpose of this chapter is to show how the Model of Software Maintenance 
can be used for the benefit of the maintenance organization as a whole, and the maintenance 
management in particular. The intent is to show the usefulness of the Model of Software 
Maintenance as a basis for a decision sup por t system oriented towards the management of the 
maintenance teams and organizations. Such a system should be able to provide the management 
(among others) with timely information and appropriate tools to support planning of the 
maintenance schedules, tracking them with verifying milestones, providing maintenance process 
status and progress reports, and locating trouble areas in the planned schedule before it gets 
out of hand [Ref. 17]. It should also allow the management to assign maintenance tasks to 
individuals and track their progress throughout the maintenance process. It should address the 
issues of system configuration management, change control and to support adequate 
communications between different participants of the maintenance process, i.e., system users, 
members of SCCB, management and programmers [Ref.18]. 

This chapter will address the utilization of the Model of Software Maintenance in 
following areas: 

• Planning and controlling the maintenance process. 

• Configuration management and control of the maintained software. 

• Gathering and processing metrics and statistics about the maintenance process. 
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In some of the above areas complete and detailed algorithms that provide a specific way 
to use the Model and the corresponding information will be presented. In other areas a way 
to make use of the Model will be shown without going into details. The reason for this 
approach is the aspiration not to tie the Model of Software Maintenance at this time to 
particular methodologies used by software development and maintenance organizations. 

The need for a maintenance-oriented engineering database was described by Swanson 
in 1976 [Ref. 9] who also defined the basic entities of such a database and a set of basic 
maintenance summary reports. For the purposes of this chapter, we will assume existence of 
a maintenance-oriented engineering database that is built upon the Model of Software 
Maintenance. Such a database contains all of the system’s components, the information about 
the maintenance tasks and steps, and the relationships defined by the Model of Software 
Maintenance. We also assume that the entities of the engineering database (e.g., system 
components, maintenance steps) have all the necessary attributes as shown in Figure 3-1. These 
attributes define the minimal information required for the algorithms that will be presented later 
in the chapter and do not preclude definition of additional attributes. 

It should be noted that some attributes of the basic entities defined by Swanson can be 
computed automatically, using the properties of the relationships between system components 
and maintenance steps defined by the Model of Software Maintenance. For example, the 
number of source lines changed during a maintenance activity can be determined by comparing 
the primary input component and the output component of a maintenance step. 

A. PLANNING AND CONTROLLING THE MAINTENANCE PROCESS 

As explained in Chapter I, the software maintenance process is difficult to plan or predict 
due to its inherent complexities and characteristics. The Model of Software Maintenance allows 
an integrated approach to the problem of maintenance planning and leads to the definition of 
relatively simple algorithms that provide decision support for the management of the 
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Component Database Entity Attributes: 


Unique component ID. 

Date of component creation. 

Component contents. 

Type of programming language used to create the component. 
Component size (e.g., in Lines of Code (LOC')). 

Maintenance Step Entity Attributes: 

Unique maintenance step ID. 

Date of maintenance step creation. 

Software change requirement description. 

SCCB decision concerning the maintenance step. 

Maintenance step description. 

Programmer assigned to implement the maintenance step. 
Estimated execution effort for a maintenance step. 

Actual effort spent on execution of a maintenance step. 
Maintenance step execution starting time. 

Maintenance step execution completion time. 

Figure 3-1: Required Attributes for Engineering Database Entities. 


maintenance teams and organizations. These algorithms can help managers plan the required 
size and expertise of the maintenance team, predict completion of a specific maintenance task, 
estimate the time to clear the backlog of maintenance request given a team of programmers, 
etc. 

This section will address maintenance step scheduling, programmer’s job assignment, 
maintenance process simulation and process execution control aspects of maintenance process 
planning and control. 

1. Scheduling Maintenance Steps 

Scheduling maintenance steps is one of the activities that the management must 
undertake in order to maintain the system efficiently and consistently. In the Model of Software 
Maintenance, maintenance step scheduling serves as the authorization to execute a step. For the 
steps with a generic primary input, it results in a generic-to-specific input resolution. 
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Scheduling of the maintenance steps must take into account the current state of the 
maintenance process, all of the requests for change that are cleared for implementation by the 
SCCB, the urgency of the required changes to the system, and the imposed sequencing 
constraints. It also must assure that the consistency of the system (as it is defined in the 
Model) will be preserved. Since scheduling is based on the changing state of the system 
configuration, the scheduling decisions depend on time. 

The necessary constraints for the correct maintenance step scheduling in the context 
of the Model of Software Maintenance can be met by the following guidelines: 

(3-1) Maintenance task scheduling can be performed only on pending maintenance 
steps. 

(3-2) A necessary condition for a maintenance step to be scheduled is that its primary 
input is available (see rule (2-24)). 

(3-3) A step Mp can be scheduled for implementation iff -i3 a step M m I M q is 
implementing or pending and M, precedes Mp. 

(3-4) If step M,, precedes step M,, then the step Mp will be scheduled before the step 

M, 

(3-5) If -^3 a "precedes" relationship between steps Mp and M,, and step M q precedes 
another step M, that has a higher priority than Mp, then the step M^ will be 
scheduled before the step Mp. 

(3-6) If rules (3-4) and (3-5) do not apply, then the step with the higher priority value 
will be scheduled first. 

It should be noted that by the definition of the specific input designation, specific 
inputs are always available for the maintenance steps. Therefore rule (3-2) influences only 
pending maintenance steps with a generic primary input designation. If there are several 
maintenance steps with the same generic primary input, then, since scheduling one of these 
maintenance steps "ties up" the primary input component (i.e., makes it unavailable to others), 
none of the other maintenance steps with the same generic input can be scheduled at this time. 

Decisions about which of the maintenance steps with the same generic primary 
input should be scheduled before others are based on rules (3-4)-(3-6). For cases in which a 
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decision based solely on these rules cannot be reached, the decision process can be augmented 
using a "rule of thumb" type of scheduling with the oldest pending step first, etc. 


A scheduling algorithm that is based upon the Model of Software Maintenance and 
that satisfies the above constraints is presented in Figure 3-2. This algorithm utilizes graph 
theory, and it determines vertex basis of an acyclic digraph that represents the relevant 
relationships between maintenance steps. Since the vertex basis (i.e., a minimal set of vertices 
that reach all vertices of a digraph) of an acyclic d i rected graph is unique [Ref. 19], 
maintenance steps that belong to the vertex basis can be scheduled concurrently without mutual 
interference or input deadlocks. 

In the first phase of the algorithm, a digraph D is created using all existing atomic 
pending maintenance steps as its vertices. The "precedes" relations between the pending steps 
are represented as arcs of the digraph D, and (in the second phase) vertex priority values are 
computed for each vertex by assigning it the maximum of priority values of all vertices that 
it can reach. 

In order to represent the existing "precedes" relations between implementing and 
pending steps, a dummy vertex M. is introduced (in the third phase of the algorithm), and the 
relevant relations are mapped as arcs between the dummy and the pending steps. Assuming that 
die vertex priority values are non-negative integers with zero representing the lowest priority 
value, in order to prevent the need to recompute vertex priority values the M. vertex is 
assigned priority zero. 

Phase four of the algorithm performs generic-to-specific input resolution. In order 
to do so, the digraph D is partitioned into generic subdigraphs D, in such a way that each 
subdigraph contains only those maintenance steps that have the same generic primary input 
component. It should be noted that in this partition uD^D and tyriDj = 0 for i *]. For each 
subdigraph D„ a single maintenance step that is to be scheduled before all other steps in the 
subgraph is determined, using the vertex priority values that were computed earlier and 
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1. Create digraph D as follows: 

a. V M q eM pending atomic step with available primary input <=> V(D). 

b. V M'MptD, step precedes step M p <-> arc (M^M^AfD) 

2. Compute vertex priority values: 

a. Assign to each vertex M q eD a priority value of a step M q . 

b. V M q e D, assign vertex priority value of Af f to the vertex highest priority value 
of set {M p eD / 3 path from to Mj. 

3. Map "precedes" relation between implementing a i pending steps: 

a. Add dummy vertex M. to D with priority value 0. 

b. V M'CD,((3 implementing M p eM \M r precedes M q ) => arc (M.M,)eA(D)). 

4. Perform generic-to-specific input resolution: 

a. Partition the digraph D into subdigraphs D, such that all vertices in each 
subdigraph have the same generic primary input. 

b. V DjsD determine step Af f e D, that should be scheduled before all other steps 
M p e D„ using computed vertex priority values and rules (3-2)-(3-6). 

c. V M p eDi, p*q add arcs (M f M p ) to D. 

5. Check conflicts with inducing steps: 

a. Find the vertex basis B of d : graph D. 

b. V MjzB with primary input C jt compute C C] . If C Cj *0, then V M p sB, with 
primary input C,€ C C] add arcs to digraph D as follows: 

1) If priority of step M p > priority of step M f , then add arc (M P M„). 

2) If priority of step M p < priority of step M r then add arc (M^M r )- 

6. Compute scheduling step sequence: 

a. Find the new vertex basis B’ of digraph D and remove the dummy vertex M, 
from it. 

b. Sort B’ in descending order of the computed vertex priority values. 

7. Expand inducing steps: 

a. V M f eB’ with primary input C ; , if C Cj *0, then V C,€C c , create induced steps 
M ¥h) with primary input C, and priority value of vertex M q as it was computed 
in phase 2. 

b. V inducing steps B’ place all M ¥n) immediately following the step M q . 


Figure 3-2: Maintenance Step Scheduling Algorithm. 
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applying rules (3-2)-(3-6). These rules should be applied with respect to the whole digraph 
D, i.e., they should not be limited to subgraph D, while considering some maintenance step as 
a candidate. If an automatic decision cannot be reached (especially due to the non-uniqueness 
of a generic input designation in the case of parallel genealogies), manual intervention may 
be required. Once the proper maintenance step is determined, arcs between the appropriate 
vertex and other vertices in the subdigraph D, are added to digraph D. Since the chosen vertex 
in each D, has no incoming arcs, the digraph D remains acyclic. 

At this point, the digraph D represents all atomic maintenance steps and all explicit 
and implicit precedence relationships between them. The vertex basis B of digraph D consists 
of all pending maintenance steps that are not preceded by some other steps, and, therefore can 
be scheduled for execution at this point in time. Since the digraph D is acyclic, its vertex basis 
is unique, i.e., there are no other maintenance steps that can be scheduled at this point in time 
since they do not belong to the vertex basis of digraph D. 

If an inducing maintenance step belongs to the vertex basis of digraph D, then a 
conflict may arise between this inducing step and some other maintenance steps which are also 
in the vertex basis and that have a primary input component which is influenced by the 
inducing step. In order to eliminate such conflicts, the fifth phase of the algorithm constructs 
additional dependency arcs in D between steps in B. The direction of these arcs is determined 
by comparing the computed priority values of the conflicting steps - from the vertex with a 
higher priority value towards the vertex with the lower priority value. Since the vertices in B 
do not reach one another, and due to the transitivity of the ’’less-then-or-equal" relationship 
between priority values, the resulting digraph D is still acyclic. 

In the sixth phase a new vertex basis B’ (which is also unique due to the acyclic 
nature of D) is computed. The dummy vertex M. is removed from B\ and its maintenance 
steps are sorted in descending order of the computed vertex priority values. 
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Phase seven is the last phase of the algorithm in which the inducing steps in B’ 
are expanded, i.e., necessary induced steps are created. The induced steps are assigned the 
priority value of their inducing step and are placed directly following it in the sorted step 
sequence. The resulting sequence of maintenance steps represents all maintenance steps sorted 
in the decreasing order of their computed priorities. These can be executed simultaneously 
without compromising system consistency, provided that necessary synchronization concerning 
induced and inducing maintenance steps is done. This sorted sequence is to be used for the 
execution of maintenance steps, for the programmer’s job assignments, and planning. 

Since the conflicts between maintenance tasks that may hamper their execution are 
resolved at scheduling time, the execution of the scheduled maintenance steps is fairly simple. 
The main phases of maintenance step execution are shown in Figure 3-3. Note that in cases 
with a specific primary input the first phase of the algorithm is redundant. The third phase of 
the maintenance step execution algorithm requires determination of non-primary inputs of the 
maintenance step. An algorithm to determine the input set of a scheduled maintenance step is 
shown in Figure 3-4. 

In order to compute the input set of a maintenance step for non-primitive primary 
input the algorithm is propagating non-primary inputs from a maintenance step that created the 
primary input component. In case of primitive primary input, the "is-component-of" relationship 
is used to determine the non-primary inputs. The third phase of the algorithm enforces system 
consistency in case of induced step input set determination. It should be noted that in such 
cases while the direct descendent of Q has not been completed yet, there already exists a 
"placeholder" for it in the configuration graph G. Since Qe C Cj , it is used as a primary input 
by some other induced step that is triggered by a change in the component C r The contents 
of the direct descendent of component C k will be produced when all induced steps triggered 
by Cj are completed (virtually simultaneously, due to the semi-atomic behavior of induced 
steps). 
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1. If primary input C of the step M, is generic, then take the latest descendent of C as 
a specific input. 

2. If the step M, is induced by some other step M r , then wait until step M r starts 
implementation. 

3. Compute the non-primary inputs of M r 

4. Start implementation of the maintenance step M r 

5. if the step M, is not induced by any other maintenance step and it is itself an 
inducing step (i.e. set C c * 0), then wait until all induced steps M ¥ml are completed. 

6. Complete M r 

Figure 3*3: Maintenance Step Execution Phases. 

As mentioned earlier, there may be a need for manual intervention in order to 
resolve ambiguous primary input designations and to make sure that all non-primary inputs are 
accounted for. Phase four of the algorithm in Figure 3-4 explicitly allows for such interventions 
whenever necessary. 

2. Maintenance Job Assignment 

Assigning maintenance jobs (steps) to a programmer is one of the basic tools for 
planning and control of the maintenance process. The job assignment process deals with 
matching scheduled maintenance steps to available maintenance programmers. Effective job 
assignment planning requires access to information about the programmer work force, thus 
allowing integration of some of the organizational aspects of the maintenance team within the 
Model of Software Maintenance analogous to coupling of technical aspects of software 
productions with human resource aspects as formulated by Abdel-Hamid and Madnick [Ref. 20]. 

We can view the available human resources (i.e., the maintenance programmer work 
force) as a set H that consists of entities H,eH where each H, represents a programmer that 
is a full or part time member of the maintenance team, i.e., H=(H, I H, represents a 
maintenance programmer). 








1. Set *<* = {C, I Cj is primary input of MJ. 

2. Create a temporary set of components S as follows: 

a. if C/eP (i.e., C, is primitive) then S = {C t / C t is a component ofCJ. 

b. Otherwise such that C/e 0 Mr 

3. V C t e S perform the following: 

a. if A/ f is an induced step triggered by a change in C t and C k eC Cj u{Cj}, then add 

the next direct descendent of C * t0 V 

b. Otherwise add C k to V 

4. Verify that I„ ¥h) contains all the necessary components, update manually if necessary. 

Figure 3-4: Determining Input Set of a Maintenance Step M v 

For each entity H,e H necessary minimal attributes can be defined as follows: 

• Potential workload per unit of time (e.g., month). 

• Actual workload per unit of time. 

• Subject/System/Language expertise. 

These attributes will be used later by the job assignment algorithm. Additional 
attributes for maintenance programmers (e.g., expertise levels) may be defined as well and they 
may be used in refinements of this algorithm or for additional purposes. 

A general algorithm for assigning currently scheduled maintenance steps to 
programmers is presented in Figure 3-5 . The algorithm begins by scheduling pending 
maintenance steps, and then for each scheduled step that has not been assigned yet it 
determines the programmers that have the expertise to perform the required maintenance 
activity. If a programmer with the required expertise and a free potential workload is found, 
the algorithm assigns the maintenance step to him and updates the programmer workload. This 
algorithm does not guarantee a solution optimized with respect to use of the available 
programmer work force or any other criteria, but it seems that it can be modified to do so. 
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1. Compute set M, h = {M, / Af f is currently scheduled but not yet assigned}. 

2. V scheduled steps M f eAf,* perform the fallowing: 

a. Determine set = {H, / H,eH has the expertise to do MJ. 

b. If 3 H,€ with free workload potential then 

1) Assign M f to H,. 

2) Add estimated effort to execute M n to the actual workload of H,. 

c. Otherwise can't plan on executing at this time. 

Figure 3-5: Job Assignment Algorithm. 

The job assignment algorithm takes into account the following restrictions: 

• Not every programmer can perform every maintenance job. 

• Workload potential of the maintenance programmer is finite. 

It should be noted that the job assignment algorithm explicitly shows that due to 
the previous constraints, there may exist some scheduled maintenance tasks that cannot be 
performed at a given point in time. Such cases should be addressed by the management of the 
maintenance team/organization, possibly outside the scope of the Model of Software 
Maintenance. 

Note that although the algorithm presented in Figure 3-5 does not explicitly 
mentions possibility of assignment of the same maintenance step to more than one programmer, 
it can be modified accordingly to support such feature. 

Assigning a maintenance steps to programmers is equivalent to defining a 
relationships between two disjoint non-empty sets: a set of the currently scheduled maintenance 
steps (i.e., the set {M^ I M, is currently scheduled)) and the set H that represents available 
human resources. These relationships define a bipartite digraph, and therefore the job 
assignment becomes a matching problem. Such problems have been well studied, and 
algorithms for finding optimal solution according to some defined criteria are known (e.g., the 
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"Hungarian method") [Ref. 21]. Use of such algorithms on top of hie job assignment algorithm 
shown in Figure 3-5 can provide solutions that may maximize the number of assigned 
maintenance tasks, minimize the total time to complete all scheduled maintenance tasks, 
optimize work force utilization, etc. 

3. Maintenance Process Simulation 

The job assignment algorithm presented in the previous section is based upon the 
set of currently scheduled maintenance steps and provides planning for a particular unit of time 
(e.g., month). In cases when the set of currently scheduled maintenance steps is too small to 
complete the planning for this unit of time (i.e., to provide scheduled jobs for all available 
programmers for the whole unit of time), the need for simulation of the maintenance process 
arises. Such simulation is useful for other needs as well, e.g., completion forecast of a 
particular maintenance task, analysis for the maintenance team size, future trends planning, etc. 

A general algorithm for simulation of the maintenance process is presented in 
Figure 3-6. This algorithm is based upon presuming completion of a maintenance step with 
the smallest execution time span. This is coupled with the iteration of the pending maintenance 
step scheduling and the programmer job assignment until the simulation goals are met. The 
scheduling and job assignment cycles of the simulation use algorithms presented earlier in this 
chapter. 

The accuracy of the maintenance process simulation depends among other factors 
on the following assumptions: 

• Execution time estimates for all maintenance steps are correct. 

• Maintenance steps are not aborted during the simulation. 

• The work force pool remains static during the simulation. 

• There are no new maintenance steps introduced during simulation. 
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While simulation limits have not been reached perform: 

a. Assign jobs to programmers. 

b. Find all assigned maintenance steps with minimal estimated execution time. 

c. Simulate completion of all maintenance steps found in previous phase. 

d. Re-assign (and reschedule) maintenance tasks. 

Figure 3*6: Maintenance process simulation. 

The last two of the previous assumptions may be changed in order to achieve better 
simulation or perform sensitivity analysis. For example, we can define a new hypothetical 
mainte nance team and check how hirmg/firing of programmers may affect the maintenance 
process. We also can simulate influx of new pending maintenance steps (by using some 
predetermined scenario that may be based upon the maintenance history of the system) in order 
to achieve a higher degree of reality in the simulation of the maintenance process. 

Additional improvement of simulation precision can be achieved by incorporating 
new programmer training process factors into the simulation model. For example, using the 
ideas and notation of [Ref. 22] and [Ref. 23], we can define for a new programmer an 
"Average Assimilation Delay" at a granularity level of the amount of the workload potential 
per unit of time (e.g., man-hours per month) which is going to be spent on learning and "social 
orientation". We can introduce an effective workload function W(H,,t) that will compute for a 
programmer H,e H the effective workload potential (i.e., workload potential without the effort 
spent for learning) as it depends on time of employment t. Also, we can introduce an additional 
function W*(F^,t) that will provide the effective workload potential for an experienced 
programmer HjS H that is tutoring a new programmer (e.g., H,). In analogy, additional workload 
potential functions can be introduced that take into account fluctuations of a workload potential 
for the work force depending on time of the year, holidays, etc. Naturally, all of the effective 
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workload potential functions mentioned above are dependent on organizational policies, 
structures and experiences. 

Incorporating both the programmer’s expertise data and the effective workload 
functions into the maintenance process simulation will enable a thorough analysis of the 
dynamics of maintenance team staffing. Coupled with other staffing decision factors described 
by Abdel-Hamid in [Ref. 22], this analysis may help in reaching correct decisions about the 
a staffing policy for the maintenance team. 

The ability to simulate the future of the maintenance process based upon the current 
state of the maintenance process is a very important capability for the management of the 
maintenance team. It may provide a sound basis for a variety of decision support tools targeted 
to improve the efficiency and cost-effectiveness of large systems’ maintenance. 

4. Controlling the Maintenance Process 

In essence, controlling the software maintenance process does not differ significantly 
from controlling a software project. The issue of control of software development and 
maintenance is to minimize surprises along the way (see [Ref. 24]). For the purpose of 
simplicity, we will view the control of the maintenance process as checking progress against 
plans and flagging possible crisis situations. 

The Model of Software Maintenance defines structure which allows a high degree 
of control over the maintenance process. This is mainly due to the tight integration between 
the configurational and managerial aspects of the maintenance process management [Ref. 18]. 
In the context of an engineering database this integration can provide automated support for 
the control of the maintenance process. This support allows it to provide the required services 
that were mentioned in the beginning of the chapter, e.g., to provide maintenance process status 
and to track maintenance progress. 










Previously in this chapter principles and algorithms for planning of the maintenance 
process were described. Since all the necessary data about the operational planning of the 
maintenance process is contained within the maintenance-oriented engineering database, and 
since the Model of Software Maintenance defines distinct execution states for each maintenance 
step and all possible relationships between the maintenance steps, we can see that the necessary 
information about the current state of all maintenance steps is stored in the engineering database 
as well. This information is automatically updated co n forming to the ongoing changes as the 
result of the execution of maintenance tasks. Software configuration management facilities of 
the engineering database discussed in the next section of this chapter provide an additional level 
of direct control over the maintenance process. For example, start of a maintenance step 
implementation or completion of a maintenance task are automatically recorded in the 
engineering database, and any deviation in the dates of these events may be detected 
immediately (by checking the relevant dates against the plans). 

As a result, various control reports about the ongoing state of the maintenance 
process can be generated utilizing the information in the maintenance-oriented engineering 
database. Some examples of such reports are listed below: 

• Current state of the maintenance tasks, i.e., what maintenance steps are awaiting 
decisions, what steps are in the pending state, how many maintenance steps are currently 
under execution, what maintenance tasks have been completed in a given unit of time, 
etc. 

• Summary reports about the completed maintenance tasks with all relevant information 
(e,g., estimated and actual programmer resources). 

• Exception reports, e.g., what maintenance steps where to be completed for a given 
deadline but are not. 

Assuming a programmer effort report facility within the engineering database 
environment that records efforts the programmers spent for each maintenance step they 
performed, additional control over the maintenance process can be provided by allowing 
compilation of reports like the following: 
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• Over-expenditure of maintenance effort, i.e., in which maintenance tasks the effort spent 
exceeds planned effort. 

• Late start of maintenance task execution, i.e., what maintenance steps should have started 
the implementation phase but have not done so. 

The required reports can be produced automatically (triggered by some event or 
criterion) or periodically (e.g., weekly or monthly), and since the most of the information about 
the progress of the maintenance process is gathered automatically, the effort required to produce 
the necessary reports is relatively small. Also, the required reports that reflect the current state 
of the maintenance process are highly available, i.e., they may be produced at any time. 

B. CONFIGURATION MANAGEMENT AND CONTROL 

The importance of proper configuration and control procedures for the success of the 
software maintenance was described earlier in Chapter I. According to the ANSI/IEEE Guide 
to Software Configuration Management [Ref. 11], software configuration management provides 
a common point of integration for planning, controlling and implementation activities of a 
software project during its lifecycle, is practiced within the management context of the software 
project, and provides the maintenance management with the visibility of the maintenance 
process and means to control it. 

The Model of Software Maintenance described in Chapter n was developed with the 
recognition of the importance of software configuration management issues. It uses system 
software configuration as one of the bases of the model and it supports concepts required to 
provide the necessary configuration management and control tools for a maintenance-oriented 
engineering database. 

The Model of Software Maintenance supports basic features required for any successful 
maintenance configuration management and control system (see [Ref. 17] and [Ref. 25]): 

• Record of system evolution history is provided automav . ally since all components and 
maintenance steps with their input and output sets are retained within the engineering 
database. 



• "Forking” of a component evolution line into two or more independent evolution 
lines/trees is supported by the Model. 

• Support of product release is provided since the Model captures all the necessary 
relationships between the components, their grouping into systems/products, and it defines 
and imposes consistency as well. 

• Version tracking is supported as part of the system evolution record. 

• Gathering of die necessary information for management activities (e.g., maintenance 
planning, progress tracking) is provided since all die required data is defined within the 
Model framework. 

• Support of different products within the same configuration management environment is 
provided directly by the Model together with component reusability within scope of 
different systems/products. 

As previously defined, components of the Model of Software Maintenance are non-re- 
derivable components, implicitly assumed to be source code modules. But besides the source 
code modules, the Model can also support additional types of software modules (also are non- 
re-derivable in terms of [Ref. 16]) as its components, e.g.,: 

• Specifications. 

• User documentation. 

• Programmer documentation. 

• Test data and test generation procedures. 

• Data dictionaries. 

Inclusion of these types of software modules within the framework of the Model of 
Software Maintenance expands the notions of both the configuration management and the 
control to all components and related software modules that are manipulated during the 
maintenance process. It is implicitly supported by the Model’s system/product definition 
mechanisms. Proper manipulation of these new types of software components may be further 
augmented by introduction of additional relationships. 

Consider a depends-on relationship between a system component and its documentation. 
Such relationship can be used to trigger documentation updates as a result of changes in its 
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related component, thus enforcing consistency in die documentation domain of the maintained 
software system. The "depends-on" relationship can be used to tie components with their 
specifications, test data, test generation procedures, etc. Also, reverse links can be defined, 
e.g., a "depends-on" relationship between the specifications and the components that implement 
them. Although the "depends-on” relationship is not defined within the Model of Software 
Maintenance, it can be implemented within the framework of an engineering database based 
upon the Model and tailored to the specifics of the target environment. 

Since the Model of Software Maintenance was built upon to comply with the ANSI/IEEE 
Guide to Software Configuration Management [Ref. 11], it supports the following: 

• Baseline concept. 

• Software product promotions/releases. 

• Software product versions/revisions. 

• Software product structure. 

• Software libraries. 

• Software product generation. 

In the Model of Software Maintenance a baseline B of a system S (denoted as B s ) is 
a set (C,} of unique representatives of the genealogy trees that comprise the system S, i.e.,: 

(3-7) B s * {C,IC ( e T k and T k e S} and V C ( ,C,eB s C„CjeT k => C,=Cj- 

A baseline of a system must be complete and consistent, i.e., the following holds: 

(3-8) V C, € B*, if C,eP, then V Cj such that C, is a component of C„ C, e B*. 

Otherwise 3 M, such that C.eO*, and V Cj non-primary inputs of M,, C t e B s . 

A baseline is unique in the context of a system, i.e.,: 

(3-9) V B\,B\ of a system S, if V C,e B\ 3 C,eB s 0 such that C i =C I and IB\I = IB S „I, 
then B s k = B s „. 

The baseline concept is important for configuration management and control. It introduces 
the dynamic aspects of system evolution, provides foundation for change management, and 
serves as a basis for coordinating engineering activities concerned with software evolution. 
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The evolution of a software system can be viewed as an ordered set of its baselines, where the 
ordering is based upon the time of a managerial decision to introduce (or roll-back to) a 
baseline (and not on the time of baseline creation, since it does not take into account the 
possibility of roll-backs to previously defined baseline). It should be noted that the baseline 
ordering is not directly related to the component ordering of the digraph G which is the basic 
structure of the Model of Software Maintenance, i.e., there is no direct relationship between 
topological ordering of components, and die ordering of baselines these components belong to. 

The software product promotion/release concept is supported by enforcing die formality 
of the managerial decisions concerned with the changes made to the baselines of the software 
product. In plain words, definition of a baseline (by defining components that belong to it) 
requires an explicit managerial decision, part of which is to decide whether the new baseline 
is to be released to the user or not. 

Use of the baseline concept allows implicit support of the versions/revisions concept. 
From the moment the new baseline is identified, all changes between the new baseline and the 
previous baselines are identified as well, and any new functional capabilities added to the 
system (leading to a new version) can be identified and appropriately documented. 

The software product structure is supported by a system/product concept of the Model 
of Software Maintenance which also supports the hierarchical decomposition of software 
products by the use of intermediate subsystems. For example, a software configuration item (Cl 
in terms of the IEEE Guide to Configuration Management) can be defined as a system S that 
consists of subsystems S, (i.e., S=uS, and S,nSj=0 for i*j) where each subsystem is a set of 
genealogy trees (i.e., S ( ■ (T k }). Such represen.ution defines a three level product hierarchy, 
and it can be expanded to include more levels of hierarchy by defining intermediate subsystems 
as required. 

The concept of multiple software libraries (i.e.. Controlled. Dynamic and Static libraries 
of the IEEE Guide to Configuration Management) is implicitly supported by the Model of 
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Software Maintenance. The main configuration repository of the Model (i.e., the digraph G 
defined in Chapter II) corresponds directly to the master (Controlled) library, and the Model 
of Software Maintenance centers on its structure and operations. The Dynmic library in which 
the hands-on software maintenance/development is performed and the Static library that holds 
the released versions and revisions of the software product are outside of the direct scope of 
the Model. These libraries can (and should) be defined by the configuration management 
according to organizational policies and practices. They should not influence the structure and 
operation of the master library except for trivial interfacing between them. 

The Model of Software Maintenance supports the following operations on the managed 
components within the master (Controlled) library: 

• Checkouts of software components to programmers according to their requests. 

• Authorized check-in from programmer as a result of completion of the implementation 
phase (i.e., when the maintenance step makes the transition from implementing to 
completed stale). 

• Baseline definition and baseline rollback as a result of an explicit managerial decisions. 

• Status accounting and history reports. 

It should be noted thai since there are no locks on the entities of the master library, and 
all the changes to it must be authorized in advance by a managerial decision within the 
consistency constrains imposed by the Model, there are no concurrent update conflicts. Thus 
the READ ONLY access to components within the master library is always supported as 
illustrated above by the absence of authorization for component checkout. 

Although the Model of Software Maintenance deals only with the non-re-derivable 
components, it implicitly supports the concept of software product generation. The Model’s "is- 
component-of' relationships, system/product structure definition and the consistency enforced 
by the Model allow automatic generation of software products. Since the actual generation of 
the software product requires additional information that is application dependent and concerns 
both the target machine (e.g., machine type, memory size, etc.) and the product specifics, it is 
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outside the scope of a general model (like the Model of Software Maintenance), and it should 
be implemented within the scope of the configuration management system. Since the maintained 
components may be of different types (e.g., written in different p ro gramm ing languages), 
different generation procedures may be required. In a such case, a sophisticated product 
generating sub-system (that should be a part of the configuration management and control 
system) could be implemented. Such a subsystem may utilize the configuration knowledge base 
ideas described in [Ref. 16], and its capabilities can be augmented by a rule-based expert 
subsystem that utilizes the component's attributes (e.g., component’s prog ramming language type 
can be used to determine the appropriate compiler to be used), and has additional advanced 
features (e.g., caching of intermediate compiled software product components for overall 
efficiency of the product generation). Naturally, since die Model of Software Maintenance 
enforces baseline consistency of software products, the resulting generated software product 
is consistent with itself (i.e., within the scope of its constructing components), and it will reflect 
the authorized maintenance work. 

Since the Model of Software Maintenance deals with all facets of the maintenance 
process information flow (from user request for a change, throughout SCCB deliberations until 
the maintenance step implementation and completion), the model actually supports the system 
configuration management and control actions throughout the entire process of software 
maintenance. The model also combines into one coherent framework the information and the 
control of the configuration management and control functions. It allows automation of the 
mechanics of the pure configuration management and control process (e.g., change initialization, 
status accounting, change control and tracking, etc.), and on-line tools to observe and control 
the dynamics of software maintenance process as a whole. 

A configuration management and control system based upon the Model of Software 
Maintenance has additional aspects: due to the discipline imposed by the model it supports 
improved communication and coordination with the user (e.g.. throughout well defined 
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procedures for change initiation), and it improves visibility of priorities of the requested 
changes and corresponding decisions about maintenance step implementation. As a result, 
software problem reports and change initiations are promptly and properly recorded, the 
implementation analysis and decision phase is enforced for all maintenance activities, and 
planning and control functions become part of the maintenance process. Also, since all changes 
to the system’s configuration must be approved by a pp r o p riate maintenance management levels, 
all concurrency conflicts (e.g., concurrent update of the same system component) are solved at 
these levels and they do not filter down to the programmer work force. Another beneficial 
aspect of a configuration management and control system based upon the Model of Software 
Maintenance is to help improve the Quality Assurance (QA) of the maintenance process by 
explicitly enforcing consistency (e.g., baseline consistency) and implicitly enforcing checks and 
formal decisions associated with the QA activity. 

C. GATHERING AND PROCESSING METRICS AND STATISTICS 

One of the important aspects of the maintenance-oriented engineering database is the 
maintenance process information gathering and processing. This information is very helpful in 
evaluating the effectiveness of the maintenance process and/or maintenance techniques as 
defined in [Ref. 9J. Also, it allows identification of error-prone components and a more 
accurate prediction of future maintenance costs than is usually available [Ref. 26]. 

Since the Model of Software Maintenance views system components as immutable objects 
(see Chapter I) and deletion of these components is prohibited, it is obvious that the Model 
retains historic information. Therefore, a maintenance-oriented engineering database built upon 
the Model of Software Maintenance can serve as a historic database of the system evolution. 
Because both the system components and the maintenance steps are elements of the Model of 
Software Maintenance, the information in this historic database pertains to aspects of 
maintenance process history (i.e., system evolution) and to component contents. 
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Since software faults are treated as change requests, and the engineering database contains 
the information about the faults themselves and all maintenance steps that were performed in 
order to eliminate them, we can see that the maintenance-oriented en gine e rin g database contains 
the necessary quality accounting information as well. 

Processing the data contained in die maintenance-oriented engineering database can 
provide the necessary information to evaluate the performance of the maintenance process for 
die organization as a whole or for a particular maintenance team, system, etc. Besides the basic 
maintenance summary reports defined by Swanson in [Ref. 9], additional computations and 
summary reports can be produced utilizing the data in the engineering database, e.g.,: 

• Average number of lines of code (LOC) changed per maintenance task for system as a 
whole or for particular subsystems. 

• Average programming effort required for the execution of a maintenance task for the 
whole system or for particular subsystems. 

• Maintenance programmer productivity for the whole system or as function of a particular 
component, subsystem or programming technology (e.g., computer language). 

• Programmer fault insertion rates as a function of time, subsystem, component or 
programming technology (e.g., computer language). 

• Annual rate of user change requests as a function of time or subsystem. 

• Annual Change Traffic (ACT) values for the whole system and/or the system 
components. 

• Maintenance effort distribution as a function of subsystems or system components. 

• System/subsystem development spoilage as function of time. 

• Changes in system complexity (e.g., McCabe cyclomatic measure) as a function of system 
evolution. 

As shown above, the required computations and reports can be produced for the whole 
system, for particular subsystems and components, or for a particular programming technology 
(e.g., computer languages and tools). This feature may be very useful for systems that consist 
of components that employ different programming technologies and techniques, which is a very 
likely feature in a large software system. 


64 






The analysis that can be performed using the historic information in the engineering 
database can be of great help in high level prediction/pianning of the maintenance process. 
For example, we can estimate the financial impact of system maintenance utilizing COCOMO 
[Ref. 8] and using correct ACT values that were computed from the information in the 
engineering database. In general, maintenance process historical information can help 
management to predict more efficiently the maintenance costs. As a result, it may also help to 
reduce the cost of system maintenance - two important goals of maintenance team/organization 
management. 

Most of the information required for the maintenance metrics and statistic is 
collected/recorded automatically dining the execution of a maintenance process and already 
exists in the engineering database. Therefore, unlike current practices of metrics and statistics 
data gathering that may consume a considerable effort [Ref. 24], there is a very low overhead 
involved in retrieving the necessary data for the required metrics and statistics computations. 
Also, the availability of the necessary data allows ad hoc generation of statistical reports that 
reflect the current state of the maintenance process. 
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IV. CONCLUSION 


This thesis presents a Model of Software Maintenance for large scale computer systems. 
In the fust chapter of this work the issues of software maintenance were examined with 
emphasis on the specific maintenance problems of military software, and the need for a 
maintenance -oriented engineering database is established. Also a need for a consistent 
underlying model for the engineering database is identified. Such a model, called the Model 
of Software Maintenance, is proposed in the second chapter of the thesis. The third chapter 
shows how to utilize the proposed Model for the purposes of maintenance process management, 
assuming that the Model serves as a theoretical basis for a maintenance-oriented engineering 
database. In particular, algorithms are provided for maintenance task scheduling, programmers 
job assignment, maintenance process planning, etc. Also, benefits of integration and automation 
of different aspects of the maintenance process (e.g., gathering and processing maintenance 
metrics and statistics) are shown. 

Special emphasis was given in the development of the Model of Software Maintenance 
to comply with the existing standards, e.g., the Guidance on Software Maintenance document 
from the USA National Bureau of Standards and the ANSI/IEEE Guide to Software 
Configuration Management were consulted and followed as closely as possible throughout the 
Model definition. 

Also, special attention was given in definition of the Model of Software Maintenance to 
stay within the theoretical aspects of mathematical modelling without incorporating specific 
organizational and implementation aspects into the Model. This was done to keep the model 
abstract enough to be used as a basis for engineering database implementation in different 
organizations, each with its own organizational structure and policies. 
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The Model of Software Maintenance was developed using an integrated approach to 
software maintenance. Change control, configuration management and control, relationships 
between software components, managerial aspects of controlling the maintenance process and 
managing available human resources are consolidated into one framework. This feature of the 
Model is unique, i.e., we do not know about any other model of software maintenance or 
production that does so. The existing practical approaches to change control and configuration 
management (i.e., implementations of change control and CM systems) address single aspects 
of the software maintenance and provide little integration capabilities with other facets of 
maintenance process. 

A. RESEARCH CONTRIBUTIONS 

The mam contribution of this research is the development of the Model of Software 
Maintenance. 

The Model of Software Maintenance provides a unique, integrative framework that 
describes the dynamic, configurational and managerial aspects of software maintenance process. 
It imposes a well defined structure on the maintenance process, provides control over the 
process lifecycle, allows automatic gathering of maintenance statistics, preserves maintenance 
history, and allows rollback of the "ill fated" maintenance tasks influence. 

The Model of Software Maintenance provides a mathematically sound basis for 
implementation of a maintenance-oriented engineering database, and it allows derivation of 
algorithms required for effective and efficient utilization of such database. Some of these 
algorithms were introduced in Chapter III of this thesis, some are still to be developed in the 
future. The resulting engineering database is capable of supporting the required information flow 
and control necessary for successful management of the maintenance process. 

The Model of Software Maintenance also imposes a well defined discipline on the 
process of software maintenance within the scope of the organization that uses the software 
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system, and, as a result, it contributes to improved communication between users and the 
system maintained. 


B. FUTURE DIRECTIONS 

It appears that at this stage of its development die Model of Software Maintenance is 
complete and consistent by itself. 

It seems logical to advise that future theoretical efforts within the framework of the 
Model should concentrate on improvement of the existing algorithms and development of 
nLatabase, e.g., access to the data, processing of the raw data using specific algorithms and 
processing data requests for the database users (e.g., SCCB members, maintained, managers, 
etc.). 

Since all of the entities in the Model of Software Maintenance can be represented as data 
entities, it seems that the heart of the functional database kernel can be implemented using a 
regular database 3 system (e.g., currently available commercial DBMS). The functionality of the 
kernel should be provided by additional software that is built upon the DBMS services. This 
software should implement the necessary algorithms (e.g., maintenance step scheduling, job 
assignment, etc.) traversing the mathematical structures of the Model of Software Maintenance. 

The flexible engineering database kernel interfaces should be responsible for the task of 
adapting the kernel to specific organizations. Such adaptation depends on the details of the 
organizational structure and peculiarities of the maintenance process in each organization. Since 
these specifics are difficult to foresee, the kernel interfaces must be flexible and sufficiently 
general. Naturally, a choice of database technology for the functional kernel (e.g., relational or 
object oriented) should not impede the flexibility and generality of the kernel interfaces. 


Regular here means usual information database and is in contrast to the maintenance oriented 
engineering one. 
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The implementation of the maintenance-oriented engineering database based upon the 
Model of Software Maintenance should address issues of the database schema design, 
appropriate database technology choice, the database operation and evaluation. 

Although the Model of Software Maintenance is oriented (as its name suggests) towards 
the maintenance phase of the software system life cycle, it can also be adapted to software 
development, especially when an evolutionary software development approach is used. Because 
this thesis concentrates on the maintenance aspects, no attempt was made to pursue this issue 
within the scope of this research. Doing so in the future may be a good idea, especially after 
the Model proves itself in a successful implementation. 
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